Codecov Report

Attention: Patch coverage is 94.73684% with 1 line in your changes missing coverage. Please review.

Project coverage is 56.11%. Comparing base (a57e030) to head (827bbca).
Report is 1 commits behind head on main.

❗ There is a different number of reports uploaded between BASE (a57e030) and HEAD (827bbca). Click for more details.

HEAD has 6 uploads less than BASE

Flag	BASE (a57e030)	HEAD (827bbca)
	6	1
docs	1	0

@@            Coverage Diff             @@
##             main      #21      +/-   ##
==========================================
- Coverage   63.40%   56.11%   -7.30%     
==========================================
  Files           6        5       -1     
  Lines         276      278       +2     
==========================================
- Hits          175      156      -19     
- Misses        101      122      +21     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

I think the unaliasing logic makes sense, although it might be sensible to have a special code path for specific cases where map!(f, a, a) is being called, since there you would probably simply loop a[i] = f(a[i]) without having to worry about zeroing out the storage.

I tried refactoring the code taking this and your comment about when to call zero! into account, please take a look (that was the goal of checking the pattern of stored values, but I agree that isn't efficient in general).

This being said, looking at the code a bit more, I think this still is not handling zeropreserving and nonzeropreserving functions very well either right? Probably we should open an issue for that, since I would say that silent wrong results are way worse than throwing errors

I think the logic right now is correct and safe but maybe not necessarily efficient, since it relies on allocating a prototypical unstored element and checking it is zero which may involve allocating a big array, in the case of sparse arrays of arrays. It is definitely something we should reevaluate and try to come up with a better design. I'll open an issue. (EDIT: Opened in #22.)